Недавно мы писали о полезных утилитах командной строки виртуального модуля VMware vCenter Server Appliance (vCSA), которые могут пригодиться при ежедневном администрировании виртуальной инфраструктуры VMware vSphere. А сегодня поговорим о сервисах vCSA - как они запускаются, и как ими управлять.

Первичный порядок загрузки служб vCenter Server Appliance выглядит следующим образом (приведены в порядке запуска):

• lwsmd (Likewise Service Manager)
• vmafdd (VMware Authentication Framework)
• vmdird (VMware Directory Service)
• vmcad (VMware Certificate Service)
• vmware-sts-idmd (VMware Identity Management Service)
• vmware-stsd (VMware Security Token Service)
• vmdnsd (VMware Domain Name Service)
• vmware-psc-client (VMware Platform Services Controller Client)
• vmon (VMware Service Lifecycle Manager)

А где же такие службы, как vmware-vpostgres, vpxd и прочие? Все просто - их запускает служба vmon. Это новый watchdog-сервис, который управляет службами vCSA в vSphere 6.5 и унифицирует доступ к ним через API.

Чтобы увидеть, в каком порядке она запускает прочие сервисы, выполним команды vmon-cli для остановки и запуска служб vmon на сервере vCSA:

/usr/lib/vmware-vmon/vmon-cli --batchstop ALL 

/usr/lib/vmware-vmon/vmon-cli --batchstart ALL

Вывод будет примерно таким:

root@vc01 [ /var/log/vmware/vmon ]# grep "Executing op START on service" vmon-sys 

17-12-12T09:44:23.639142+00:00 notice vmon Executing op START on service eam... 

17-12-12T09:44:23.643113+00:00 notice vmon Executing op START on service cis-license... 

17-12-12T09:44:23.643619+00:00 notice vmon Executing op START on service rhttpproxy... 

17-12-12T09:44:23.644161+00:00 notice vmon Executing op START on service vmonapi... 

17-12-12T09:44:23.644704+00:00 notice vmon Executing op START on service statsmonitor... 

17-12-12T09:44:23.645413+00:00 notice vmon Executing op START on service applmgmt... 

17-12-12T09:44:26.076456+00:00 notice vmon Executing op START on service sca... 

17-12-12T09:44:26.139508+00:00 notice vmon Executing op START on service vsphere-client... 

17-12-12T09:44:26.199049+00:00 notice vmon Executing op START on service cm... 

17-12-12T09:44:26.199579+00:00 notice vmon Executing op START on service vsphere-ui... 

17-12-12T09:44:26.200095+00:00 notice vmon Executing op START on service vmware-vpostgres... 

17-12-12T09:45:33.427357+00:00 notice vmon Executing op START on service vpxd-svcs... 

17-12-12T09:45:33.431203+00:00 notice vmon Executing op START on service vapi-endpoint... 

17-12-12T09:46:54.874107+00:00 notice vmon Executing op START on service vpxd... 

17-12-12T09:47:28.148275+00:00 notice vmon Executing op START on service sps... 

17-12-12T09:47:28.169502+00:00 notice vmon Executing op START on service content-library... 

17-12-12T09:47:28.176130+00:00 notice vmon Executing op START on service vsm... 

17-12-12T09:47:28.195833+00:00 notice vmon Executing op START on service updatemgr... 

17-12-12T09:47:28.206981+00:00 notice vmon Executing op START on service pschealth... 

17-12-12T09:47:28.220975+00:00 notice vmon Executing op START on service vsan-health...

Как мы видим, службы запускаются в следующем порядке:

• eam (VMware ESX Agent Manager)
• cis-license (VMware License Service)
• rhttpproxy (VMware HTTP Reverse Proxy)
• vmonapi
• statsmonitor
• applmgmt
• sca (VMware Service Control Agent)
• vsphere-client
• cm
• vsphere-ui
• vmware-vpostgres (VMware Postgres)
• vpxd-svcs
• vapi-endpoint
• vpxd (VMware vCenter Server)
• sps (VMware vSphere Profile-Driven Storage Service)
• content-library
• vsm
• updatemgr
• pschealth
• vsan-health

Утилиту vmon-cli можно использовать для запуска и остановки этих сервисов в следующем формате:

/usr/lib/vmware-vmon/vmon-cli -r ServiceName

Например, чтобы перезагрузить vSphere Client, можно использовать команду:

/usr/lib/vmware-vmon/vmon-cli -r vsphere-client

Известный своими скриптами блоггер Luc Dekens (LucD) опубликовал интересный сценарий PowerCLI для виртуальной инфраструктуры VMware vSphere, который позволяет вычистить права доступа на объекты, для которых уже существуют права на уровне родительских объектов.

Например, у вас есть такая картина:

Соответственно, нам нужно почистить пермиссии в папке Test1131 для пользователя Local\test, чтобы разрешения остались только на уровне родительского объекта Test1 (там, как мы видим, установлена опция применения разрешений вниз к дочерним объектам).

Собственно, сам скрипт:

<#
.SYNOPSIS
  Find and remove redundant permissions on vSphere objects 
.DESCRIPTION
  The function will recursively scan the permissions on the
  inventory objects passed via the Entity parameter.
  Redundant permissions will be removed.
.NOTES
  Author:  Luc Dekens
.PARAMETER Entity
  One or more vSphere inventory objects from where the scan
  shall start
.EXAMPLE
  PS> Optimize-Permission -Entity Folder1 -WhatIf
.EXAMPLE
  PS> Optimize-Permission -Entity Folder?
.EXAMPLE
  PS> Get-Folder -Name Folder* | Optimize-Permission
#>
 
  [cmdletbinding(SupportsShouldProcess=$true)]
  param(
    [parameter(ValueFromPipeline)]
    [PSObject[]]$Entity
  )
 
  Begin{
    function Optimize-iVIPermission{
      [cmdletbinding(SupportsShouldProcess=$true)]
      param(
        [parameter(ValueFromPipeline)]
        [VMware.Vim.ManagedObjectReference]$Entity,
        [VMware.Vim.Permission[]]$Permission = $null
      )
 
      Process{
        $entityObj = Get-View -Id $Entity
        $removePermission = @()
        $newParentPermission = @()
        if($Permission){
          foreach($currentPermission in $entityObj.Permission){
            foreach($parentPermission in $Permission){
              if($parentPermission.Principal -eq $currentPermission.Principal -and
                 $parentPermission.RoleId -eq $currentPermission.RoleId){
                $removePermission += $currentPermission
                break
              }
              else{
                $newParentPermission += $currentPermission
              }
            }
          }
        }
        else{
          $newParentPermission += $entityObj.Permission
        }
        if($removePermission){
          if($pscmdlet.ShouldProcess("$($entityObj.Name)", "Cleaning up permissions")){
            $removePermission | %{
              $authMgr.RemoveEntityPermission($Entity,$_.Principal,$_.Group)
            }
          }
        }
        $Permission += $newParentPermission
       
        if($entityObj.ChildEntity){
            $entityObj.ChildEntity | Optimize-iVIPermission -Permission $Permission
        }
      }
    }
  }
 
  Process{
    foreach($entry in $Entity){
       if($entry -is [System.String]){
        $entry = Get-Inventory -Name $entry
       }
       Optimize-iVIPermission -Entity $entry.ExtensionData.MoRef
    }
  }
}

Скрипт работает так, что пробегается по дереву объектов, обнаруживает избыточные разрешения и удаляет их. У скрипта есть удобный параметр WhatIf, который выводит операции по очистке разрешений, которые как бы применяются к дочерним объектам, но на самом деле не применяет их:

Optimize-VIPermission -Entity Test1 -WhatIf

Результатом будет список объектов, где разрешения будут очищены, в данном случае, если посмотреть на пример выше, это будет папка Test1131:

Можно запустить скрипт и на 2 папки сразу:

Optimize-VIPermission -Entity Test1,Test2 -WhatIf

Результат будет таким (в папке Test22 также есть дублирующиеся разрешения):

Также можно использовать и конструкции с масками, например:

Get-Folder -Name Test? | Optimize-VIPermission -WhatIf

Теперь неплохо было бы, если бы кто-то написал GUI к этой штуке, а также добавил туда функции поиска и удаления произвольных разрешений в выбранных объектах.

Как знают администраторы VMware vSphere, с выходом каждой новой версии платформы увеличиваются и максимумы для ее компонентов. Многие из этих максимумов трудно достижимы на практике, поскольку еще нет серверов такой возможности (например, для запуска такого количества машин в производственной среде), но некоторые аспекты требуют того, чтобы лимиты параметров были увеличены (например, число vNIC на одну машину иногда для тестирования нужно больше).

Давайте взглянем на эволюцию максимумов VMware vSphere в таблицах ниже, где отображены параметры версии 5.5, 6.0 и 6.5:

Максимумы виртуальных машин

Максимумы вычислительных мощностей VMware ESXi

Максимумы хранилищ VMware ESXi

Максимумы сетевого взаимодействия VMware ESXi

Мы часто пишем о виртуальном модуле VMware vCenter Server Appliance (vCSA), который представляет собой готовую виртуальную машину для управления виртуальной инфраструктурой VMware vSphere (напомним, что это полноценная замена vCenter for Windows).

Сегодня мы покажем несколько интересных утилит командной строки vCSA, которые могут помочь вам в ежедневной эксплуатации этого управляющего сервиса.

1. Просмотр журнала Cron.

vCSA имел раньше проблемы со сжатием фалов журнала (логов), что приводило к тому, что дисковые разделы быстро заполнялись. Поэтому следующей командой можно посмотреть, когда в последний раз выполнялись запланированные задачи Cron:

ls -l /var/spool/cron/lastrun/

Для сравнения ниже приведен вывод этой команды совместно с выводом текущей даты:

vc:~ # date

Mon Dec 4 12:55:39 CET 2017

vc:~ # ls -l /var/spool/cron/lastrun/

total 0

-rw------- 1 root root 0 Dec 3 20:00 cron.daily

-rw------- 1 root root 0 Dec 4 12:15 cron.hourly

-rw------- 1 root root 0 Dec 1 20:00 cron.weekly

Как мы видим, крон успешно выполнялся для ежечасной задачи, ежедневной и еженедельной. Если же крон отвалился, то значит, скорее всего, устарел пароль root. Узнать это можно следующей командой:

grep "Authentication token is no longer valid; new one required" /var/log/messages.0.log | head

Если в выводе этой команды будет что-то вроде этого:

<timestamp> vcenter /usr/sbin/cron[<ID>]: Authentication token is no longer valid; new one required

значит пароль root устарел.

2. Смена устаревшего пароля root.

Если ваш пароль root устарел, и крон-таски vCSA не запускаются, то сменить его проще всего будет следующей командой (обратите внимание, что это НЕ слово change):

chage -l root

У вас запросят старый пароль и попросят задать новый:

Password change requested. Choose a new password.

Old Password:

New password:

После этого можно снова вывести срок действия пароля с помощью chage (тут видно, что он устареет через 99999 дней, то есть 274 года):

vc:~ # chage -l root

Minimum: 0

Maximum: 99999

Warning: 7

Inactive: -1

Last Change: Dec 27, 2016

Password Expires: Never

Password Inactive: Never

Account Expires: Never

3. Перезапуск служб vCSA.

Если вы хотите поправить странное поведение vCSA, которое может быть связано с некорректным поведением сервисов Linux внутри виртуального модуля, то можно перезапустить все службы:

service-control --stop --all

service-control --start --all

Можно перезапустить, например, только vSphere Client:

service-control --stop vsphere-client

Список запущенных служб узнается так:

service-control --list

А вот так узнается статус того или иного сервиса:

service-control --status

4. Работа с LVM

Если вам надо увеличить виртуальные диски VMDK, а потом расширить тома LVM, то можете прочитать вот эту нашу статью. Чтобы не использовать API Explorer или PowerCLI, можно выполнить следующую команду для просмотра томов LVM:

lsblk

Далее вы получите примерно следующее:

vc:~ # lsblk

NAME MAJ:MIN RM SIZE RO MOUNTPOINT

sda 8:0 0 20G 0

??sda1 8:1 0 132M 0 /boot

??sda2 8:2 0 1G 0 [SWAP]

??sda3 8:3 0 10.9G 0 /

sdb 8:16 0 1.4G 0

sdc 8:32 0 25G 0

??swap_vg-swap1 (dm-8) 253:8 0 25G 0 [SWAP]

sdd 8:48 0 50G 0

??core_vg-core (dm-7) 253:7 0 50G 0 /storage/core

sde 8:64 0 10G 0

??log_vg-log (dm-6) 253:6 0 10G 0 /storage/log

sdf 8:80 0 10G 0

??db_vg-db (dm-5) 253:5 0 10G 0 /storage/db

sdg 8:96 0 5G 0

??dblog_vg-dblog (dm-4) 253:4 0 5G 0 /storage/dblog

sdh 8:112 0 25G 0

??seat_vg-seat (dm-3) 253:3 0 25G 0 /storage/seat

sdi 8:128 0 1G 0

??netdump_vg-netdump (dm-2) 253:2 0 1016M 0 /storage/netdump

sdj 8:144 0 10G 0

??autodeploy_vg-autodeploy (dm-1) 253:1 0 10G 0 /storage/autodeploy

sdk 8:160 0 10G 0

??invsvc_vg-invsvc (dm-0) 253:0 0 10G 0 /storage/invsvc

fd0 2:0 1 4K 0

sr0 11:0 1 1024M 0

Для идентификации дисковых устройств и их типов можно выполнить следующее:

lsscsi

Вывод будет примерно таков:

vc:~ # lsscsi

[0:0:0:0] disk VMware Virtual disk 1.0 /dev/sda

[0:0:1:0] disk VMware Virtual disk 1.0 /dev/sdb

[0:0:2:0] disk VMware Virtual disk 1.0 /dev/sdc

[0:0:3:0] disk VMware Virtual disk 1.0 /dev/sdd

[0:0:4:0] disk VMware Virtual disk 1.0 /dev/sde

[0:0:5:0] disk VMware Virtual disk 1.0 /dev/sdf

[0:0:6:0] disk VMware Virtual disk 1.0 /dev/sdg

[0:0:8:0] disk VMware Virtual disk 1.0 /dev/sdh

[0:0:10:0] disk VMware Virtual disk 1.0 /dev/sdi

[0:0:12:0] disk VMware Virtual disk 1.0 /dev/sdj

[0:0:14:0] disk VMware Virtual disk 1.0 /dev/sdk

[1:0:0:0] cd/dvd NECVMWar VMware IDE CDR00 1.00 /dev/sr0

Когда вы поймете, какой том нужно увеличить, выполните команду:

vpxd_servicecfg storage lvm autogrow

Надо помнить, что это сработает только для томов под управлением LVM (например, для disk 1 (sda) с разделом / - не сработает).

5. Поиск "загрязняющих" файлов.

Чтобы найти логи, которые могут засорить корневой раздел или раздел /storage/log, выполните одну из следующих команд:

du -a /var | sort -n -r | head -n 10
du -a /storage/log | sort -n -r | head -n 10

6. Изменение режима ротации логов (Log Rotation).

Сначала перейдем в папку с логами:

cd /etc/logrotate.d

Далее сделаем бэкап настроек:

cp dnsmasq ./dnsmasq.old

Затем откроем настройки:

vi dnsmasq

И поменяем слово "weekly" (еженедельно) на "daily" (ежедневно), например:

/var/log/dnsmasq.log {

daily

missingok

notifempty

delaycompress

sharedscripts

postrotate

[ ! -f /var/run/dnsmasq.pid ] || kill -USR2 cat /var/run/dnsmasq.pid

endscript

create 0640 dnsmasq dnsmasq

После этого можно удалить старый большой лог следующими командами:

cd /var/log

rm dnsmasq.log

7. Удаление файлов, которые не удалились.

Бывает так, что вы удалили большой файл, а дисковое пространство не высвободилось - и это видно командой df -h. Это происходит потому, что какой-то из процессов в памяти еще держит файл (при этом не обязательно использует его). Чтобы узнать, что это за процесс выполняем команду:

lsof | grep deleted

Вывод будет примерно таким:

postgres 8860 vpostgres 10u REG 253,4 16777216 16395 /storage/dblog/vpostgres/pg_xlog/000000010000011900000041 (deleted)

Видим, что это Postgres держит файл, поэтому если он нам сейчас не нужен, убиваем процесс:

kill -9 <PID>

После этого вы увидите, что свободного дискового пространства на сервере vCSA стало больше.

С начала ноября мы не писали про тонкий клиент на базе HTML5 для управления виртуальной инфраструктурой - VMware vSphere Client (тогда он был версии 3.27). На днях компания VMware выпустила его версию 3.30, поэтому давайте рассмотрим новые возможности, которые появились в последних трех версиях клиента - VMware vSphere Client 3.28-3.30.

Итак, что нового:

• Просмотр имеющихся лицензий (Host/Cluster/функции Solutions) - пока работает в режиме Read-Only.
• Доступны детали лицензированных продуктов и их фичей.
• Детали лицензий сервера vCenter и хостов ESXi (Host License) - доступно в разделе Configure > Licensing.
• Проверки состояния vSphere Distributed Switch (vDS health checks).
• Настройка фильтрации трафика и правил его маркировки на уровне распределенных порт-групп.
• Экспорт и импорт распределенных виртуальных коммутаторов (vDS) и распределенных порт-групп.
• Настройка политик распределенных порт-групп внутри мастера создания новой порт-группы.
• Настройка CPU Identification Mask в разделе Advanced.
• Выбор паравиртуализованного сетевого адаптера PVRDMA для сети виртуальных машин.

Скачать последнюю версию VMware vSphere Client 3.30 можно по этой ссылке.

Те из вас, кто следит за новостями VMware, знают, что некоторое время назад компания отказалась от развития своего публичного облака (ранее оно называлось vCloud Air и было продано в OVH) в пользу партнерских решений на стороне облаков сервис-провайдеров. Главным и первым из таких партнеров стала компания Amazon, которая совместно с VMware предлагает IaaS-услугу аренды виртуальных машин на базе AWS.

В мае этого года случилось невероятное: два заклятых конкурента - VMware и Microsoft - предложили совместную услугу VMware Horizon Cloud on Microsoft Azure, позволяющую получить в аренду виртуальные десктопы и приложения.

Но главная новость пришла в конце ноября - теперь две компании, жестко борящиеся за рынок серверной виртуализации, будут давать в аренду серверы VMware vSphere на оборудовании облака Azure.

Как оказалось, VMware не очень-то довольна этим фактом, но рынок есть рынок - VMware проиграла войну за публичные облака и теперь IaaS-сервисы VMware будет предлагать в том числе Microsoft.

Пока технология находится в стадии технологического превью, но есть уже первые новости от Microsoft. Вкратце они заключаются в следующем:

• Microsoft предоставит средства миграции рабочих нагрузок частного облака в инфраструктуру VMware в облаке Azure. Эти средства позволят вам обнаружить виртуальные машины VMware vSphere и связи между ними (как показано на картинке выше), а потом смигрировать их на платформу Azure. При этом заранее будут посчитаны требуемые ресурсы и, главное, примерная стоимость месячной аренды ресурсов Azure. Решение Azure Site Recovery (ASR) позволит обеспечить правильный порядок миграции и минимальное время простоя. Azure Database Migration Service позволит перенести БД SQL Server и Oracle на PaaS-платформу Azure SQL Database.
• Microsoft обеспечит интеграцию сервисов Azure и VMware. Это включает в себя такие решения, как Azure Backup, Azure Site Recovery (для Disaster Recovery-решений), управление апдейтами и конфигурациями, Azure Security Center и средства аналитики Azure Log Analytics. Кроме этого, можно будет управлять инфраструктурой и средствами VMware - с помощью консоли vRealize Automation.
• Microsoft будет развивать средства эксплуатации гибридных облаков. Это позволит создать единую гибридную инфраструктуру между онпремизным облаком VMware vSphere и виртуальными машинами на платформе Azure. Заявляется, что ВМ в облаке будут запущены на оборудовании датацентров Microsoft и ее партнеров (про загадочных партнеров очень интересно написано тут), но на серверах ("на колокейшене") как bare-metal гипервизоры будет установлен полный стек решений VMware vSphere.

Такие дела, Microsoft победила:) Несколько полезных ресурсов на почитать:

• Azure Migration Center - там утилиты, документ и описания технологий миграции, в том числе от партнеров, таких как Turbonomic, Movere и Cloudamize.
• Дополнительная информация о сценариях миграции с VMware на Azure.
• Бесплатный курс Azure for VMware vSphere Admins.

Пока идет обкатка технологического превью, а полностью сервисы VMware из облака на платформе Azure будут доступны в 2018 году.

Довольно давно мы уже рассказывали о механизме применения политик для хранилищ при развертывании виртуальных машин - VMware vSphere Storage Policy Based Management (SPBM). А недавно Кормак Хоган опубликовал интересную заметку, касающуюся возможности выбора политик SPBM конкретным пользователем во время развертывания новой виртуальной машины.

Прежде всего, в vSphere нет механизма назначения прав доступа пользователей на конкретную политику SPBM - все пользователи видят все политики. Но сам механизм разграничения прав существует - его можно реализовать на уровне прав доступа к хранилищам.

Например, пользователю ben мы даем доступ Read-only к хранилищу VVols1, то есть создавать виртуальные машины он на нем не может:

А на хранилище VVols2 делаем его администратором:

В итоге, при развертываниии виртуальной машины пользователь ben видит оба хранилища - VVols1 и VVols2 и все доступные политики хранилищ (комбобокс VM storage policy):

Однако, обратите внимание, что при выборе хранилища VVols1 в разделе Compatibility написано о том, что пользователь не имеет достаточных привилегий, чтобы создать машину на этом датасторе.

You do not hold the privilege to allocate space on the selected datastore

Между тем, кнопка Next активна. Но если нажать ее, мастер все равно дальше не пустит:

Вверху мы увидим:

Specify a valid location

Ну а если выбрать VVols2, то все проверки пройдут успешно, и пользователь сможет там создать виртуальную машину:

Гостевой пост сервис-провайдера ИТ-ГРАД, предоставляющего виртуальные машины из облака IaaS в аренду.

В статье «Миграция в облако» мы рассказывали о частичном и полном переходе на облачную площадку, рассматривали примеры реальных кейсов, затрагивая наиболее распространенные ошибки. Сегодня поговорим о том, какие инструменты помогают мигрировать между различными облаками и когда возникает такая необходимость.

Зачем мигрировать

На практике нередки ситуации, когда требуется перенести виртуальные машины с одной площадки на другую, например из частного облака компании в публичное облако IaaS-провайдера. Это актуально и тогда, когда наблюдается мгновенная нехватка собственных ресурсов или клиент решает сменить поставщика облачных услуг. Миграция между облаками также может быть вызвана изменениями в законодательстве. К слову сказать, многие иностранные компании, осуществляющие деятельность на территории РФ, размещали собственные информационные системы, а с ними и персональные данные россиян на зарубежных облачных площадках. Но с выходом ФЗ-152 «О защите персональных данных» потребовалась миграция в облака российских поставщиков.

Так, известная во всем мире компания VBH («Фаубеха») — крупнейший дистрибьютор товаров и услуг для оконных, дверных производств — столкнулась с задачей внедрения нового на тот момент ERP-решения Microsoft Dynamics Axapta 2009. Компания размещала собственную инфраструктуру в облачном дата-центре на территории Германии. Используя единое облачное пространство, удалось создать стандартизированную инфраструктуру с такими ERP-решениями, как Microsoft Dynamics Navision, Axapta, 1С и SAP.

С выходом нового закона, который обязал хранить персональные данные на территории Российской Федерации, потребовалось перенести часть систем в Россию. Сервис в результате разместился на площадке российского облачного провайдера «ИТ-ГРАД». Об опыте подобных переездов расскажем ниже. Читать статью далее ->>

Бывает, что попытке развернуть виртуальную машину из шаблона (Template) вы получаете сообщение об ошибке "Customization of the guest operating system is not supported in this configuration":

Как правило, это происходит из-за того, что в машине не установлены VMware Tools. Просто сконвертируйте шаблон в ВМ, потом включите ее и установите тулзы, после чего конвертируйте машину опять в Template.

Также такая ситуация бывает, когда vCenter не поддерживает гостевую ОС виртуальной машины для кастомизации, либо когда развертывание происходит на NFS-хранилище, для которого не включена опция "no root squash".

С момента выхода последнего мажорного релиза платформы виртуализации VMware vSphere 6.5 мы много писали о шифровании виртуальных машин (и, кроме того, затрагивали тему производительности этого процесса), а также техниках шифрования кластеров vSAN (и некоторых особенностях этого). Сегодня мы поговорим о самом важном компоненте инфраструктуры шифрования vSphere - Key Management Service (KMS).

Прежде всего, KMS - это сервисы шифрования не только для виртуальных машин, но и любых других объектов ИТ-инфраструктуры. Поэтому KMS уже может быть в вашей организации, при этом он может не быть прикрученным к VMware vSphere. Вы можете использовать любой KMS-сервер, но VMware сертифицировала лишь следующие системы из списка (см. вот этот документ VMware):

Если же у вас другой KMS-провайдер, не расстраивайтесь - он, скорее всего, будет работать, если поддерживает протокол управления ключами KMIP 1.1.

Начать надо с вопросов доступности KMS-сервера. Как вы понимаете, это самый важный сервер в вашей инфраструктуре, важнее DNS или контроллера домена. Если у вас недоступен DNS, все тоже не работает, как и в случае с KMS, но если оказались недоступными данные хранилища KMS - это катастрофа для организации. И нет абсолютно никакого пути восстановить их. Совершенно никакого. Обо всем этом рассказывает видео ниже:

Таким образом, KMS становится бизнес-критичной точкой не только инфраструктуры, но и бизнеса в целом. И вопросы бэкапа и его доступности - это вопросы номер 1. Давайте посмотрим на несколько базовых понятий KMS:

• KMIP (Key Management Interoperability Protocol) - это стандарт, по которому клиент KMIP может общаться с серверами KMS. Каждый год он проходит серьезную проверку на конференции RSA.
• DEK (Data Encryption Key). Это ключ, который хост ESXi генерирует, когда требуется зашифровать виртуальную машину. Этот ключ используется также и для расшифровывания данных ВМ, он записан в VMX/VM Advanced settings в зашифрованном виде.
• KEK (Key Encryption Key). Это ключ, которым зашифрован DEK. KEK key ID также находится в VMX/VM Advanced settings.
• Key Manager Cluster/Alias - это коллекция адресов FQDN/IP всех реплицируемых между собой серверов KMS. Она также хранится вместе с зашифрованной машиной в VMX/VM Advanced settings, чтобы после ее включения можно было обратиться к нужному кластеру KMS, получить KEK для cервера vCenter, который разлочит ВМ.
• VM и vSAN encryption - это, на самом деле, с точки зрения реализации механизма шифрования одно и то же. То есть, для обоих типов шифрования используются одни и те же библиотеки, конфигурации и интерфейсы.

Когда мы говорим о кластере KMS - это всего лишь KMS-серверы, реплицирующие между собой хранилища ключей. Они не обеспечивают доступность друг друга, как, например, это делает VMware HA. Например, есть серверы KMS-A, KMS-B и KMS-C, в хранилищах которых при добавлении ключа новой ВМ он появляется мгновенно.

Если KMS-A недоступен как сервер, то сервер vCenter запрашивает ключи у хоста KMS-B. Если же KMS-A недоступен как сервис (то есть сервер работает, а служба KMS не отвечает), то vCenter ждет 60 секунд восстановления работоспособности сервиса и только потом переключается на KMS-B. Это поведение изменить нельзя.

Лучшие практики по использованию KMS таковы:

• По возможности нужно делегировать обязанности по поддержке инфраструктуры KMS отдельной команде (Security Team) или человеку.
• Не класть KMS-серверы в виртуальной машине в тот же кластер (например, vSAN), который также зашифрован. Иначе коробочка закроется (выключится кластер), а ключ от нее останется внутри нее же. То есть, необходимо держать хотя бы один из KMS-серверов за пределами такого домена отказа.
• Предыдущий пункт относится и к серверам vCenter и PSC. Чтобы они могли расшифровать другие сервера, они должны быть доступны в случае сбоя.

Теперь надо сказать о катастрофоустойчивости серверов KMS. Типичный кластер в рамках одной площадки выглядит так:

Но если на этой площадке будет авария, которая затронет все 3 сервера - бизнесу может настать конец. Поэтому в идеале надо использовать конфигурацию с двумя площадками:

Понятное дело, что у малого и среднего бизнеса резервных площадок, как правило, нет. В этом случае помочь может публичное облако Amazon AWS или Microsoft Azure. Чтобы поддерживать там одну резервную машину, много денег не нужно.

Ну и если вы используете конфигурацию с несколькими площадками, то обязательно нужно учитывать в конфигурации порядок обращения к серверам KMS в рамках площадки. Если на первой площадке находятся сервера KMS-A, KMS-B и KMS-C, а на второй - KMS-D, KMS-E и KMS-F, то в первом случае порядок должен быть A,B,C,D,E,F, а во втором - D,E,F,A,B,C.

Если на второй площадке вы будете использовать конфигурацию аналогичную первой, сервер vCenter может ходить по серверам другой площадки, которая может быть недоступна, а только обойдя все ее серверы, начнет использовать локальные KMS.

Мы много пишем о технологии Virtual Volumes (VVols), которая сравнительно недавно появилась в платформе виртуализации VMware vSphere. Совсем недавно мы писали о том, что будет в следующих версиях VVols, а сегодня давайте посмотрим на текущее положение дел.

Eric Siebert написал интересный пост о том, сколько компаний использует VVols сейчас в производственно среде. На данный момент VVols применяется примерно у 2% клиентов VMware, что весьма и весьма мало. Связано это, в первую очередь, с ограничениями технологии и небольшим количеством партнеров ее поддерживающих.

Между тем, подвижки в этом направлении уже есть. Вот какие факторы будут способствовать развитию VVols в ближайшем будущем (Эрик считает, что более половины всех пользователей vSphere будут применять эту технологию):

• Все больше клиентов переходят с vSphere 5.5 на vSphere 6.x, где VVols полностью поддерживаются.
• В vSphere 6.5 поддерживается функциональность аппаратной репликации томов VVol, что является очень важной и нужной фичей.
• Партнеры расширяют поддержку этой технологии в своих новых массивах.
• Клиенты все больше узнают о технологии, в том числе через этот пост:)

Если посмотреть на статистику использования VVols администраторами vSphere в различных компаниях, то во времени она выглядит так:

В принципе, прогресс за этот период выглядит неплохо (особенно в категории 100+), но в абсолютном выражении это, все-таки, очень мало. Ну и вот небольшой августовский отчет IDC про данную технологию - "VVols Provides Powerful Application-Aware Management for vSphere Environments".

Пара интересных роликов, вышедших на днях:

Не так давно мы публиковали несколько интересных заметок о VMware Tools (раз, два, три, четыре), которые объясняют множество моментов, касающихся развертывания и эксплуатации данного пакета, предназначенного для улучшения работы гостевых ОС в среде виртуализации VMware vSphere.

В этой заметке мы постараемся обобщить эти вещи и добавить еще несколько фактов о VMware Tools, которые должен знать каждый администратор платформы ESXi:

• Пакет VMware Tools для основных гостевых ОС входит в состав ESXi, но остальные поставляются отдельно от дистрибутивов платформы, и их можно скачать отсюда.
• Чтобы узнать версии тулзов для ОС Windows и Linux, идущие вместе с дистрибутивом ESXi или патчем, загляните по этой ссылке https://packages.vmware.com/tools/versions (а мы писали об этом вот тут).
• Стандартные VMware Tools, которые подходят для большинства ОС Windows и Linux можно обновлять через VMware Update Manager (VUM). Они накатываются в виде VIB-пакетов под названием "tools-light".
• Традиционный подход к обновлению VMware Tools на множестве хостов VMware ESXi - это использовать общий репозиторий для VMware Update Manager, который накатывает обновления на серверы. Более современный подход - это использовать механизм Auto Deploy для развертывания stateless-хостов, которые забирают актуальные версии VMware Tools прямо из онлайн-репозитория VMware.
• Версии VMware Tools состоят из двух релизов - VMware Tools 10.1.x и VMware Tools 10.0.x (это два разных ISO-образа). Версия 10.1.x - это развивающаяся ветка для современных гостевых систем (сейчас актуальна 10.1.15), а 10.0.12 - замороженная, которая предназначена для устаревших ОС, которые уже не обновляются. То есть апгрейд с версии тулзов 10.0.9 происходит на 10.1. Подробнее об этом рассказано в KB 2015161.

• Почти все Linux-дистрибутивы идут с интегрированной версией Open VM Tools.
• ISO-файлы VMware Tools теперь идут с файлами контрольных сумм, по которым можно проверить соответствие пакетов на аутентичность их происхождения за счет сверки хэшей. Поэтому надо быть внимательным при распаковке составляющих пакета, и ничего оттуда не убирать.
• Для VMware Tools, начиная с версии 10.1, доступна подробная документация.
• Все новые версии VMware Tools обратно совместимы со всеми версиями VMware ESXi, которые моложе как минимум на одно поколение. В этом можно убедиться, посмотрев VMware Interoperability Matrix:

• Для Linux существует 3 вида VMware Tools (подробнее тут):
  • Operating System Specific Packages (OSP) - пакеты, которые размещены на сайте VMware (их можно скачать/обновить без аутентификации), содержащие в себе те же самые компоненты, которые находятся в ISO-образах, идущих с дистрибутивами VMware ESXi. Этот метод поставки VMware Tools для Linux уже несколько устарел и используется для старых гостевых ОС.
  • Open VM Tools (OVT) - это пакеты VMware Tools с открытым исходным кодом, которые встраиваются в большинство современных Linux-дистрибутивов. Соответственно, при установке такой гостевой ОС в виртуальной машине, пакет VMware Tools будет там уже установлен. Исходный код OVT доступен для всех желающих в репозитории на GitHub, но официально поддерживаются только те OVT, которые идут вместе с дистрибутивами Linux. Если вы скомпилировали их самостоятельно - учтите, поддержки от VMware не будет.
  • TAR Tools - они предоставляются VMware и устанавливаются через сценарий. Но VMware рекомендует использовать OVT.
• VMware Tools дают множество возможностей для виртуальной машины и гостевой ОС, обо всех них написано вот тут.
• Виртуальные машины с Windows используют паравиртуализованные драйвера хранилищ и сетевых адаптеров, что улучшает взаимодействие гостевой ОС и соответствующих ресурсов. Вот почему после обновления тулзов машина хочет перезагрузиться.
• Для унификации развертывания VMware Tools нужно настроить централизованный репозиторий и сконфигурировать хосты ESXi таким образом, чтобы они брали последние версии тулзов оттуда. Об этом мы подробно писали вот тут, также вкратце информация есть об этом здесь и здесь.

Если у вас есть еще интересные моменты на эту тему - пишите в каменты!

Наш читатель Стас обратил внимание на то, что в начале ноября компания VMware выпустила значительное обновление для шестой версии платформы виртуализации VMware vSphere 6.0. Были опубликованы апдейты и патчи для ESXi 6.0 - ESXi600-201711001.

В составе гипервизора и прочих компонентов были обновлены следующие пакеты ESXi 6.0:

• VMware_bootbank_esx-base_6.0.0-3.79.6921384
• VMware_bootbank_vsan_6.0.0-3.79.6766495
• VMware_bootbank_vsanhealth_6.0.0-3000000.3.0.3.79.6769065
• VMware_bootbank_esx-dvfilter-generic-fastpath_6.0.0-3.79.6921384
• VMware_bootbank_misc-drivers_6.0.0-3.79.6921384
• VMware_bootbank_ipmi-ipmi-devintf_39.1-5vmw.600.3.79.6921384
• VMware_bootbank_ipmi-ipmi-msghandler_39.1-5vmw.600.3.79.6921384
• VMware_locker_tools-light_6.0.0-3.76.6856897

Обновления коснулись новых возможностей, подсистемы безопасности и исправлений наиболее серьезных ошибок. Чтобы скачать апдейт, нужно пойти на VMware Patch Portal, выбрать ESXi 6.0 и ввести там номер билда (6921384).

Правильно устанавливать обновление нужно следующими командами (если, конечно, на хосте есть интернет):

esxcli network firewall ruleset set -e true -r httpClient

esxcli software profile update -p ESXi-6.0.0-20171104001-standard -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

esxcli network firewall ruleset set -e false -r httpClient

Кроме того, на днях также было выпущено обновление VMware vCenter 6.0 Update 3c. Там появилось три основных новых улучшения:

• Включенная поддержка SMB2 для виртуального модуля vCenter Server Appliance 6.0 Update 3c, чтобы избежать уязвимости протокола SMB1.
• Совместимость с решениями VMware vSphere Replication 6.1.2.1 и VMware Site Recovery Manager 6.1.2.1.
• Улучшения кластеров VMware Storage DRS.

Получить больше информации об обновлении VMware vCenter 6.0 Update 3c можно по этим ссылкам:

• VMware-VIMPatch-6.0.0-7037384-20171101.iso
• VMware-vCenter-Server-Appliance-6.0.0.30300-7037817-patch-TP.iso
• VMware-vCenter-Server-Appliance-6.0.0.30300-7037817-patch-FP.iso

Скачать vCenter 6.0 u3c можно по этой ссылке.

Автор известного технического блога о платформе VMware vSphere, Frank Denneman, совместно с одним из коллег выпустил весьма интересную книгу "vSphere 6.5 Host Resources Deep Dive".

В рамках 570-страничного талмуда авторы рассказывают все технические детали управления ресурсами на уровне хоста ESXi, такими как память, процессор, стек работы с хранилищами и сетевая архитектура. Довольно много содержимого книги посвящено архитектуре NUMA-узлов и оперативной памяти, механикам работы CPU и ядра VMkernel, а также прочим самым глубоким моментам программных и аппаратных компонентов хоста ESXi.

По уверению авторов книга покрывает, например, следующие технические вопросы:

• Оптимизация рабочих нагрузок для систем Non-Uniform Memory Access (NUMA).
• Объяснение того, как именно работает механика vSphere Balanced Power Management, чтобы получить преимущества функциональности CPU Turbo Boost.
• Как настроить компоненты VMkernel для оптимизации производительности трафика VXLAN и окружений NFV.

В общем, книга очень крутая и мудрая. Скачать ее можно по этой ссылке.

В середине октября мы писали о новых возможностях VMware vSphere Client версий 3.22-3.24. Напомним, что этот тонкий клиент на основе технологии HTML5 скоро заменит собой устаревающий Web Client на основе Adobe Flex. За последние 3 недели компания VMware успела выпустить целых три версии vSphere Client 3.25, 3.26 и 3.27.

Давайте посмотрим на новые возможности этих версий клиента:

• Всплывающее окно файлового менеджера Datastore File browser. Также была улучшена его производительность и информативность окна загрузки (показаны файлы в очереди и общий объем загружаемого контента).
• Добавление лицензии для хостов vSphere и возможность задания ее имени в рабочем процессе добавления. Также можно ее переименовывать и удалять.
• Просмотр свойств лицензий (лицензированных продуктов и технологий на хостах).
• Просмотр ассетов лицензии vCenter (в режиме read-only).
• Редактирование свойств и политик для распределенных портов vDS.
• Можно развернуть ВМ из шаблона, выбрав мастер создания новой ВМ, далее Deploy from template > вкладка Data center.
• Операция Rescan теперь выполняется параллельно на уровне датацентра и кластера.
• Группами Replication groups можно управлять через действие Edit VM Storage Policy.

Скачать VMware vSphere Client 3.27 можно по этой ссылке.

На прошедшем VMworld 2017 компании VMware и Amazon представили IaaS-решение публичного облака - VMware vCloud on AWS. Штука эта довольно дорогая, и чтобы попробовать ее, нужно заводить аккаунт на Amazon, платить за его сервисы и прочее.

Но есть и более простой путь, чтобы посмотреть, как это работает вживую - лабораторная работа "VMware Cloud on AWS Hands-on Lab". Зарегистрировавшись на портале MyVMware, в течение 60 дней вы будете иметь доступ к лабораторной работе, в рамках которой вы сможете поиграться с виртуальным датацентром VMware vSphere на стороне публичного облака AWS в рамках терминальной сессии.

На время выполнения лабы можно создать кластер из 4 хостов ESXi:

Ну и далее можно просматривать состояние датацентра, настраивать сетевое взаимодействие между компонентами и заходить на свою инфраструктуру через vCenter:

Сама лабораторная работа рассчитана на полчаса, за которые вы вполне поймете, как это выглядит и управляется. Ну и бонусом технический обзор облака VMware vCloud on AWS:

Также не забывайте про специальный Youtube-канал, посвященный решению VMware vCloud.

Как многие из вас знают, в конце лета и начале осени прошли главные конференции по виртуализации этого года - VMworld 2017 и VMworld Europe 2017. Об основных анонсах мероприятий мы писали по этой ссылке, но в рамках этих ивентов было еще столько всего, что обо всем, конечно же, не напишешь.

Специально для тех, кто хочет узнать тонкости всех докладов, которые были представлены на конференциях, компания VMware создала репозиторий на GitHub, где содержатся вообще все ссылки на сессии, многие из которых дадут много новой информации и технических деталей о продуктах и технологиях виртуализации от VMware:

Сессии доступны как в виде роликов на Youtube, так и виде PDF-документов.

Ну а вот список самых популярных сессий (топ-10 по числу просмотров на Youtube):

• [SER1143BU] - A Deep Dive into vSphere 6.5 Core Storage Features and Functionality [NET1152BU] - Introduction to VMware NSX
• [SER1534BUR] - vSphere Performance Troubleshooting and Root Cause Analysis
• [VIRT1309BU] - Monster VMs (Database Virtualization) with vSphere 6.5: Doing IT Right
• [NET1345BU] - NSX in Small Data Centers for Small and Medium Businesses
• [SER2724BU] - Extreme Performance Series: Performance Best Practices
• [VIRT1430BU] - Performance Tuning and Monitoring for Virtualized Database Servers
• [ADV1587BU] - NSX + VMware Horizon: A Security Architecture for Delivering Desktops and Applications with VMware
• [SER2355BU] - Best Practices for All-Flash Arrays with VMware vSphere
• [SER2965BU] - Advanced Troubleshooting of ESXi Server 6.x for vSphere Gurus
• [SER2077BU] - Achieve Maximum vSphere Stability with PowerCLI Assisted Documentation: From Buildout to Daily Administration

Оказывается, у VMware есть интересная утилита с открытым исходным кодом - Weathervane. Это бенчмаркинг-тул, предназначенный для запуска тестов производительности в виртуальных средах VMware vSphere (как онпремизных, так и облачных), с учетом симуляции реальной нагрузки различных приложений. Утилита доступна в открытом репозитории на GitHub.

Weathervane позволяет, например, снять метрики с двух различных окружений или его конфигураций, что позволит выбрать наиболее производительную конфигурацию виртуального окружения и выставить самые эффективные настройки виртуальной среды. Также с помощью Weathervane компания VMware сама делает различные тесты, к примеру, вот документ о производительности контейнеров Docker в виртуальной среде VMware vSphere - "Performance of enterprise web applications in Docker containers on VMware vSphere 6.5".

Weathervane имеет возможности по развертыванию нескольких независимых экземпляров приложения и его отдельных сервисов в контейнерах Docker, запуску различных нагрузок и конфигурации параметров их исполнения для измерения необходимых метрик производительности. То есть, это утилита для бенчмаркинга производительности именно на уровне приложений.

Weathervane состоит из трех основных компонентов:

• Приложение (Auction application), которое развертывается в среде тестирования.
• Драйвер рабочей нагрузки (Workload driver), который выдает реалистичную нагрузку для приложения с учетом заданных параметров тестирования.
• Компонент исполнения (Run harness), который автоматизирует процесс исполнения тестовых запусков приложения и собирает результаты, логи и, собственно, данные о производительности.

Также в составе Weathervane есть Supporting tools, которые включают в себя скрипты для настройки экземпляра операционной системы со всем необходимым для запуска утилиты, создания образов Docker и подготовки приложения для запуска в среде тестирования.

При проведении тестирования вы можете изменять следующие параметры:

• Число экземпляров на уровне каждого сервиса. Например, может быть любое число балансировщиков нагрузки, серверов приложений или узлов веб-серверов. Это позволяет создавать конфигурации любого масштаба.
• Число ярусов целевой архитектуры. Например, вы можете не использовать некоторые компоненты, такие как балансировщики и веб-сервера, если вам нужно протестировать небольшую по объему среду.
• Вариант развертывания среды. Например, Weathervane сейчас поддерживает PostgreSQL и MySQL в качестве транзакционной БД, а также Apache Httpd и Nginx в качестве веб-серверов. Ну и надо помнить, что это open source проект, а значит вы сами можете расширять его.
• Конфигурацию сервисов. В настроечном файле можно изменять параметры для каждого из ярусов, которые будут применяться компонентом run harness перед началом каждого прогона бенчмарка.

Для больших инфраструктур и тестовых сред Enterprise-приложений Weathervane предоставляет следующие средства:

• Вы можете запускать экземпляры приложения напрямую в ОС, неважно в физической или виртуальной машине, а также в контейнерах Docker (это позволит сравнить эти варианты развертывания между собой по производительности). Как мы писали выше, Weathervane содержит скрипты для создания образов Docker для всех сервисов приложений.
• Вы можете задать пользовательскую нагрузку для экземпляров приложения, которая позволит оценить поведение приложения при критических нагрузках, циклических паттернах нагрузки и поведение сервиса в плане эластичности.
• Поддерживается изменение числа экземпляров приложения прямо во время исполнения теста, что позволит снять метрики, относящиеся к эластичности сервиса (то есть его способности динамически выделять и освобождать ресурсы при изменении нагрузки). В будущем будет также добавлен мониторинг поведения среды в реальном времени, чтобы оперативно оценивать эластичность и инертность сервиса по отношению к нагрузке.

Руководство по использованию VMware Weathervane доступно по этой ссылке. Ну а сам проект Weathervane на GitHub доступен тут: https://github.com/vmware/weathervane.

Компания VMware выпустила полезную администраторам VMware vSphere диаграмму компонентов, соединений и портов, посвященную решению vRealize Operations Manager 6.6. Напомним, что о самом продукте vROPs 6.6, выпущенном летом этого года, мы писали вот тут.

Коммуникации, обозначенные на диаграмме рассматриваются как на уровне кластера, так и в рамках компонентов одного узла. Слева на плашках приведены комментарии для различных уровней - на зеленом фоне пояснение принципов взаимодействия между компонентами и требования продукта (например, необходимость обеспечения 5 ms latency между узлами или пояснения к механизму HA), а на синем фоне детально рассказывается об устройстве ноды, ее компонентах - сервисах, базе данных, адаптерах и прочем.

На странице KB о диаграмме vRealize Operations Manager 6.6 есть ссылка на загрузку файла в формате PDF.

Недавно компания VMware выпустила интересный документ VMware vSphere APIs for I/O Filtering (VAIO), в котором описываются основные принципы работы данной технологии. Ниже мы расскажем о них вкратце, а также затронем тему того, каким образом можно использовать VAIO в производственной среде.

VAIO - это технология и API, которые позволяют получать прямой доступ к потоку ввода-вывода (I/O Stream) гостевой ОС виртуальной машины. Механизм VAIO уже сейчас способствует созданию партнерских продуктов для решения самых разнообразных задач (например, кэширование write-back и write-through). VAIO основан на механике Storage Policy Based Management (SPBM), которая предназначена для управления правилами хранения виртуальных машин и их работой с хранилищами.

Техническая реализация данного механизма подразумевает использование драйвера VAIO (filter driver), который устанавливается на хосте VMware ESXi как пакет VIB и не требует установки никакого специального ПО в гостевой ОС виртуальной машины.

Посмотрим на эту картинку, на которой изображен путь данных от виртуальной машины к физическому устройству хранения. На ней представлены 2 компонента, относящиеся к VAIO. Первый - это VAIO фреймворк, работающий на уровне ядра VMkernel и определяющий действующую политику фильтра. Второй - это IO Filter, представляющий собой программное обеспечение, работающее на уровне пользовательской среды исполнения (User World) сервера ESXi. Этот драйвер фильтра исполняет свою функцию (например, кэширование данных или их репликация), после чего передает их на физическое устройство хранения для записи.

Такая архитектура позволяет драйверу IO-фильтра получать доступ к потоку ввода-вывода, не сильно не влияя на производительность исполнения SCSI-команд. Еще одна особенность IO-фильтра - это возможность иметь доступ к потоку ввода-вывода как в сторону записи (от ОС к хранилищу), так и в обратную сторону (квитанции о прохождении команд). Это полезно, например, при использовании IO-фильтра для технологии репликации, где очень важно получать квитанции о записи данных на диск.

Кстати, SCSI-команды попадают к IO-фильтру сразу после того, как они проходят слой эмуляции SCSI (он же vSCSI), что позволяет использовать VAIO для любых типов хранилищ - VMFS, NFS, SCSI и vSAN. Ну а перехват команд IO-фильтром перед их отсылкой в сетевой стек к хранилищу позволяет обеспечить целостность данных и безопасность.

Еще, если внимательно посмотреть на архитектуру прохождения потока ввода-вывода, можно заметить, что драйвер IO-фильтра работает на уровне User World, а значит в целом не влияет на стабильность работы сервера ESXi. Даже если он вдруг прекратит свою работу, основной стек прохождения SCSI-команд, расположенный в ядре, продолжит работать в нормальном режиме.

Работает IO Filter на уровне отдельных VMDK-дисков конкретных ВМ, что открывает широкие возможности для механизма политик Storage Policy Based Management (SPBM) и применения их к отдельным виртуальным машинам и сервисам.

Все вышеперечисленное позволяет применять VMware VAIO при решении следующих типов задач:

• Encryption – стороннее ПО за счет использования механизма VAIO может на лету шифровать и расшифровывать поток данных от виртуальной машины. Таким образом на хранилище будут помещаться уже шифрованные данные. Гранулярность работы VAIO позволяет обслуживать данные, идущие даже не от всей виртуальной машины, а только от одного приложения.
• De-duplication - этот механизм уже использует решение VMware Virtual SAN. В реальном времени можно дедуплицировать данные, проходящие через драйвер и в таком виде уже класть на хранилище в целях экономии дискового пространства. Эта техника доступна и партнерам VMware.
• Tiering - данные различной степени важности, критичности или классифицированные по другим критериям теперь можно класть на хранилища с разными характеристиками производительности и доступности (ярусы). Механизм VAIO тут поможет проанализировать характер данных и определить конечное их место назначения.
• Analytics - теперь можно анализировать непосредственно поток данных от конкретной виртуальной машины и на основе этого строить множество различных решений, включая решения по кэшированию (например, такой продукт как PrimaryIO, который можно напрямую подключить к гипервизору). Затем можно, например, искать в трафике данные определенных приложений, либо, использовать механизм write-back кэширования.

Технология VAIO работает, начиная с VMware vSphere 6.0 Update 1, поддерживает горячую миграцию vMotion (VAIO должна быть доступна на целевом хосте) и кластеры VMware DRS (должна быть доступна на всех хостах).

Давайте теперь посмотрим, как VAIO работает на практике на одном из примеров. Чтобы начать работать с VAIO, вам нужно установить IO Filter в виде VIB-пакета, который реализует функциональную составляющую партнерского продукта для VMware vSphere.

Как правило, вместе с фильтром идет и политика SPBM (аналогичная тем, которые есть для vSAN или VVols, например), которую можно назначать виртуальным машинам на уровне виртуальных дисков VMDK.

Эту политику можно назначить при создании виртуальной машины в разделе Select Storage (в данном случае это политика кэширования на SSD):

Пример политики, идущей вместе с фильтром, как правило включает в себя Common Rule - правила, которые реализуют Data Services (то есть основной функционал фильтра) и определяются через компоненты Storage Policy Components (путем добавления компонентов в разделе Common Rules).

Например, в данном случае это тип кэширования Write Through или Write Back, который мы задаем в разделе Common Rules при создании новой политики хранения:

По умолчанию эти компоненты устанавливаются вместе со встроенными фильтрами vSphere и другими продуктами, которые пополняют набор IO-фильтров, а соответственно и компонентов по мере их установки. За счет использования Storage Policy Components возможности IO-фильтров могут быть включены в любую из уже настроенных политик VM Storage Policies.

Это очень удобно, поскольку на данный момент виртуальная машина или VMDK-диск могут иметь только одну примененную к ним политику хранения, но к ним можно добавить компоненты от разных фильтров.

Ну а сами IO-фильтры от разных производителей вы можете найти в VMware Compatibility Guide по этому адресу - https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vaio.

Как видно из картинки, на данный момент не так много партнеров используют технологию VAIO для своих продуктов, а категорий решений всего две - репликация и кэширование. Но VMware активно работает в этом направлении, и в скором времени, возможно, мы увидим еще несколько продуктов, реализующих функционал IO-фильтров для решения новых задач.

Один из блоггеров, пишущих о платформе VMware vSphere (у него есть кстати симулятор экзамена VCDX), выложил на GitHub интересный документ, который может оказаться полезным администраторам больших виртуальных инфраструктур и сотрудникам системных интеграторов - vTestPlans.

Это документ, доступный в форматах Microsoft Word и PDF, представляет собой план тестирования виртуальной инфраструктуры VMware vSphere. Да, пока он еще весьма небольшой и очень приблизительный, но автор уверяет, что будет развивать и расширять его, в том числе за счет помощи от участников сообщества VMware.

Штука эта на самом деле полезная, когда вы в какой-нибудь компании внедряете VMware vSphere и хотите проверить работоспособность программно-аппаратного комплекса в целом после развертывания.

На днях некоторые пользователи VMware vSphere заметили, что их браузер Google Chrome крашится при попытке доступа через VMware vSphere Web Client на базе технологии Adobe Flex к серверу vCenter. Баг обнаружил William Lam и другие пользователи vSphere.

В этом случае Хром вываливается вот с такой ошибкой:

Shockwave Flash has crashed

При этом ни перезапуск хрома, ни перезапуск системы не помогает избавиться от ошибки.

Вся фишка в том, что Google выпустила обновление библиотеки Flash (27.0.0.170) вместе с последним обновлением браузера Chrome (61.0.3163.100), которое имеет ошибки при работе с флешем, причем не только для продуктов VMware. Одним из временных решений проблемы было бы использование браузера Firefox, но и там используется такая же библиотека Flash.

Ну а чтобы вылечить Google Chrome нужно сделать вот что:

1. Найти старую библиотеку pepperflashplayer.dll для Google Chrome (например, для Windows она выложена здесь) и положить ее в папку 27.0.0.170 вашей директории Chrome.

Находится эта папка вот тут:

• Windows - %LocalAppData%\Google\Chrome\User Data\PepperFlash
• Mac OS - ~/Library/Application Support/Google/Chrome/PepperFlash

2. Отключить функции автоматического обновления Google Chrome. Для этого в ключе реестра:

HKLM\SOFTWARE\Policies\Google\Update\AutoUpdateCheckPeriodMinutes

нужно выставить значение 0. После этого Chrome должен заработать с vSphere Web Client:

На Mac OS, кстати, старая версия библиотеки сохраняется в папке 27.0.0.159, поэтому вы просто можете скопировать ее в новую папку 27.0.0.170 и залогиниться в vSphere Web Client.

Баг этот очень неприятный, но в этот раз VMware не виновата. Накосячили в Гугл и Адоби. Флеш умирает сам:)

Следить за обновлениями о баге можно по этой ссылке.

В сентябре мы писали о новых возможностях тонкого клиента vSphere Client 3.21, предназначенного для управления виртуальной инфраструктурой через браузер на базе технологии HTML5. За прошедший месяц вышли обновленные версии VMware vSphere Client 3.22, 3.23 и 3.24, о новых возможностях которых мы расскажем ниже.

Итак, что нового появилось в vSphere Client (на картинке выше, кстати, скрин кастомизации ОС):

• Возможность кастомизации всех сетевых настроек, включая шлюз по умолчанию, при применении спецификации кастомизации гостевой ОС виртуальной машины (при клонировании или кастомизации существующей ВМ).
• Добавление контроллера NVMe для новой или существующей ВМ.
• Улучшенное представление просмотра деталей о совместимости в мастере развертываниия новой ВМ.
• Возможность загрузки папки из файлового браузера.
• Группы DRS могут быть отфильтрованы по их составляющим хостам.
• В портлете VM Storage Policy отображаются Replication groups.
• Можно посмотреть список установленных VIB-пакетов (на vSphere 6.5).
• Редактирование информации о видеокарте для виртуальной машины.
• Пофикшено множество багов, в том числе касающихся снапшотов.

Скачать VMware vSphere Client 3.24 можно по этой ссылке.

Как многие из вас знают, в рамках платформы VMware vSphere коммуникация между ее компонентами происходит на базе SSL-сертификатов. Если на сервере vCenter вы используете собственные сертификаты с ограниченным сроком действия, то их надо регулярно продлять и обновлять, иначе однажды вы не сможете выполнять привычные операции в виртуальной инфраструктуре.

Например, если сертификат vCenter устареет, то при попытке выполнить горячую миграцию vMotion, вы получите сообщение о невозможности соединения с демоном vpxd и ошибкой "server certificate chain not verified" в консоли vSphere Client. Если при этом посмотреть вот в этот лог-файл:

/var/log/vmware/vmware-sps/sps.log

то можно увидеть там подобные сообщения:

com.vmware.vim.vmomi.client.exception.SslException: com.vmware.vim.vmomi.core.exception.
CertificateValidationException: Server certificate chain not verified

Чтобы посмотреть сроки действия текущих сертификатов, нужно воспользоваться следующими командами на хосте vCSA (vCenter Server Appliance):

/usr/lib/vmware-vmafd/bin/vecs-cli entry list –store MACHINE_SSL_CERT –text |less

/usr/lib/vmware-vmafd/bin/vecs-cli entry list –store machine –text |less

По умолчанию сервер vCenter предупреждает администратора об истечении срока действия сертификатов за 30 дней. О том, как заменить сертификаты хорошо рассказано вот тут.

Этот срок можно поменять, для этого:

• Зайдите в vSphere Web Client.
• Выберите vCenter Server, перейдите на вкладку Manage и далее в подвкладку Settings.
• Нажмите Advanced Settings, далее Edit и введите в фильтр слово "threshold".
• Измените значение ключа vpxd.cert.threshold на нужное количество дней.

Ну а чтобы аларм об истечении сертификатов точно сработал, нужно зайти в Alarm settings –> Certificate Status и убедиться, что установлена галка Enable this alarm.

Источник.

Не так давно мы писали о новой версии решения VMware vCloud Director 9.0 для сервис-провайдеров, которое позволяет управлять публичной облачной инфраструктурой на основе платформы VMware vSphere.

Вместе с vCloud Director был анонсирован и входящий в его состав продукт VMware vCloud Extender, который был ранее хорошо известен вам как vCloud Connector. Давайте посмотрим, что это такое.

В первую очередь, VMware vCloud Extender - это средство, с помощью которого пользователи облачных инфраструктур могут перенести свои онпремизные виртуальные машины в облако. Причем средство это бесплатное.

Вот из каких компонентов состоит vCloud Extender на стороне сервис-провайдера:

• Виртуальный модуль Extender Manager appliance - развертывается как виртуальная машина под управлением vCenter Server провайдера. Креды расшариваются с самим vCD.
• Виртуальный модуль Replication Manager appliance - предоставляет управление задачами репликации между клиентами и провайдером.
• Виртуальный модуль Replicator appliance - отвечает за репликацию состояний выбранных виртуальных машин.

Развертывание vCloud Extender со стороны провайдера выглядит очень просто:

На стороне клиента vCloud Extender состоит из следующих компонентов:

• Виртуальный модуль Extender Connector appliance - он соединяется с Extender Manager на стороне сервис-провайдера. Также он регистрируется как плагин на сервере vCenter.
• Replicator - реплицирует информацию о состоянии для выбранных ВМ на vCD.
• Виртуальный модуль NSX Edge Appliance - это опциональный компонент, который требуется для горячих миграций ВМ. При этом он предоставляет VPN-соединение на уровне L2 (если это доступно) и обеспечивает сетевую связность для миграций в рамках единого пространства IP-адресов между сервис-провайдером и клиентом.

После установки vCloud Extender на стороне клиента он получает элегантный HTML5 веб-интерфейс:

Ну и здесь, собственно, видны три основных функции, которые может исполнять vCloud Extender:

• Настройка соединения к вашему Virtual Data Center (vDC) на стороне сервис-провайдера.
• Создание соединений Layer 2 за счет коммуникации между компонентом Edge и vCloud Director.
• Миграция виртуальных машин, которая может проходить как в холодном, так и в горячем режиме.

Доступность vCloud Extender ожидается в ближайшем будущем, но точные сроки его выхода пока не определены.

На днях компания VMware объявила о доступности новой версии решения VMware vCloud Director 9.0, предназначенного для управления облачной инфраструктурой VMware vSphere для сервис-провайдеров, предоставляющих услуги IaaS (Infrastructure-as-a-Service). В этот раз это большое обновление. Напомним, что прошлая версия vCloud Director 8.20 вышла в марте этого года.

Давайте посмотрим на новые возможности VMware vCloud Director 9.0:

• Новый пользовательский интерфейс на базе HTML5 (показан на видео выше). Он доступен по ссылке https://{vCD _URP_IP}/Tenant/{organization_name}, однако старый UI на базе технологии Adobe Flex по-прежнему доступен.
• Новые рабочие процессы для жизненного цикла виртуальных машин.
• Функции управления для клиентов (чере Tenant portal), объекты которых находятся в разных датацентрах (Virtual Data Centers) под управлением разных экземпляров vCloud Director. Делается это через единый URL, в котором федерирован доступ ко всем инстансам vCD. Соответственно, для пользователя работает единый вход (Single Sign-On), что позволяет ему не вводить пароль на разные экземпляры vCD. Но для этого нужно будет замапить сайты между собой и настроить ассоциации типа site-to-site.
• Компонент Distributed Logical Router (DLR) который маршрутизирует трафик между сетями Org vDC. Функциональность DLR находится в ядре ESXi, развертывается через решение VMware NSX, а логически находится между сетью Org vCD network и шлюзом Edge Gateway.
• В качестве основной БД теперь поддерживается PostgreSQL версии 9.5, помимо MS SQL и Oracle. Также поддерживается соединение по SSL и кластерные конфигурации. А утилита Cell Management Tool (CMT) поможет провести миграцию с MS SQL или Oracle на PostgreSQL.
• Шлюзы Edge gateways могут быть размещены в отдельных пулах ресурсов.
• Возможность горячей миграции хранилища между датасторами на уровне клиента (Tenant). Это позволит, например, остановить дисковый массив на обслуживание, предварительно убрав все виртуальные машины клиентов.
• Поддержка транкинга для внешних сетей и Routed Org Networks.
• Поддержка latency между vCenter Server и vCloud Director до 100 миллисекунд.
• Группы безопасности (Security Groups), которые позволяют динамически определять и применять политики безопасности.
• Новый Plugin Framework для написания сторонних расширений к продукту.
• Новый интерфейс HTML5 Metrics UI. Теперь базовые метрики ВМ показываются на портале клиентам.

Следующие ОС могут быть использованы, как платформа для vCloud Director 9.0:

• CentOS 6
• CentOS 7
• Oracle Linux 6
• Oracle Linux 7
• Red Hat Enterprise Linux 6
• Red Hat Enterprise Linux 7

Мы рассказали лишь о самых важных новых возможностях VMware vCloud Director 9.0. Полный их список приведен в документе "vCloud Director 9.0. What's New". Скачать vCD 9.0 можно по этой ссылке.

Это гостевой пост сервис-провайдера ИТ-ГРАД, предоставляющего услуги аренды виртуальных машин из облака.

Каждый раз попадая на высокотехнологичное ИТ-мероприятие, проводимое VMware, сюда хочется вернуться вновь и вновь. Вот и в этом году, по уже сложившейся традиции, инженеры «ИТ-ГРАД» отправились на конференцию VMworld Europe 2017, которая второй раз подряд проходила в одном из известных конгресс-центров Барселоны Fira Gran Via.

Накануне официального открытия здесь совсем мало народу.

На целых четыре дня это место превратилось в инновационную площадку, ярко демонстрирующую то, как современные технологии меняют повседневную жизнь человека. И каким бы ни было тяжелым утро понедельника, первые сессии стартовали в 8:30, продолжаясь до позднего вечера. На повестке дня – разговоры об инновациях в бизнес-мобильности и облачной инфраструктуре.

Каждый, кто хотя бы раз посещал VMworld знают, что помимо технических докладов, мероприятия такого формата славятся впечатляющим набором развлекательных активностей. Тут вам и выступления популярных музыкантов, и интерактивные демонстрации, и лаунж зоны, где можно перевести дух между сессиями, поиграть в напольные шахматы, бильярд или шестиметровый настольный футбол. Читать статью далее->>

Многие администраторы больших виртуальных инфраструктур VMware vSphere, в которых работают кластеры отказоустойчивых хранилищ VMware vSAN, часто задаются вопросом, какой дисковый контроллер выбрать для организации хранения на хостах ESXi.

Дункан Эппинг дает простую рекомендацию - надо брать один из самых недорогих поддерживаемых контроллеров, который имеет большую глубину очереди (Queue Depth). Например, часто в рекомендациях для vSAN можно встретить контроллер Dell H730, который является весьма дорогим устройством, если брать его на каждый сервер.

Но его не обязательно покупать, достаточно будет дискового контроллера Dell HBA 330, который и стоит дешевле, и глубину очереди имеет в 10 раз больше, чем H730 (хотя оба они соответствуют требованиям vSAN). Да, у H730 есть кэш на контроллере, но он в данном случае не требуется. Лучше использовать интерфейс NVMe для подключения отдельного SSD-кэша, не затрагивающего RAID-контроллеры (его нужно размещать как можно ближе к CPU).

Поэтому итоговая рекомендация по выбору дискового контроллера для кластеров vSAN проста - берите любое недорогое устройство из списка совместимости vSAN Compatibility Guide, но с хорошей глубиной очереди (например, HP H240), а на сэкономленные деньги отдельно организуйте кэш на базе NVMe.

Еще на VeeamON 2017 весной этого года компания Veeam Software рассказала о новом решении Veeam Powered Network (Veeam PN), которое стало первым продуктом Veeam в области сетевого взаимодействия.

Вот его небольшой видеообзор от Anthony Spiteri, евангелиста Veeam:

Veeam PN - это простое средство для организации VPN между всеми компонентами вашей инфраструктуры - главным офисом, филиалами и подразделениями, удаленными работниками и т.п. Решение построено на базе открытой технологии OpenVPN и представляет собой специальную виртуальную машину, работающую в облаке Microsoft Azure (Veeam PN Server) или на стороне частного облака клиента, а также компоненты на стороне оконечных потребителей (Veeam PN Gateway):

Помимо готовой машины Veeam PN на стороне Azure, в качестве центрального координационного сервера, выполняющего функции маршрутизации, можно использовать обычную ВМ в онпремизной инфраструктуре VMware vSphere. Для этого нужно загрузить и развернуть виртуальный модуль Veeam PN Appliance в формате OVA.

Надо отметить, что Veeam PN - это полностью бесплатный продукт, который является сетевой подложкой для комплексного решения по обеспечению катастрофоустойчивости датацентров Veeam Recovery to Microsoft Azure. Но Veeam PN можно использовать и как простой VPN для предприятий, которым необходима простая в развертывании инфраструктура виртуальной частной сети.

Архитектура сетевой инфраструктуры Veeam PN может быть любой, например, может быть топология, где есть виртуальная машина Veeam PN Server на стороне Azure, клиентское ПО Veeam PN Gateway в трех географически разделенных датацентрах, а также отдельные внешние пользователи частной сети, подключающиеся с помощью клиента OpenVPN Client.

При развертывании продукта нужно выбрать одну из двух опций:

Network Hub - это сервер Veeam PN, который развертывается в облаке Azure или в частной инфраструктуре, а Site gateway - это виртуальная машина, выступающая как шлюз для Veeam PN. Для коммуникации используются 2048-битные самоподписанные сертификаты. Первоначальная настройка сервера выглядит так:

Далее мы задаем опции сетевой коммуникации:

• Network hub public IP or DNS name - это публичный адрес, к которому должны иметь доступ все члены частной сети, включая удаленных клиентов вне частных облаков, которые будут подключаться к инфраструктуре.
• Enable site-to-site VPN - эту опцию надо поставить, если необходима коммуникация между датацентрами (между Veeam PN Gateways).
• Enable point-to-site VPN - эти настройки выставляются для коммуникации между клиентом OpenVPN Client и компонентом Veeam PN Gateway на стороне датацентра.

После того, как вы развернете Veeam PN сервер, нужно сгенерировать настройки для сетей датацентров (сценарий site-to-site) и отдельных компьютеров (сценарий point-to-site). Для этого нужно зарегистрировать сайты и компьютеры на стороне Veeam PN Server (Hub portal):

В итоге мы получим список зарегистрированных площадок и отдельных клиентов:

После того, как вы зарегистрируете клиентов, надо будет скачать настройки VPN для площадок и клиентов в формате XML. Далее эти настройки нужно будет импортировать при развертывании Site Gateway:

Если сервер Network Hub развернут в онпремизной сети, вам нужно добавить новый маршрут на шлюзе по умолчанию (Default gateway) в онпремизной сети, где у вас развернут Veeam PN Server, а также в сетях площадок, где есть Site Gateways, чтобы обе стороны VPN-туннеля знали маршрут (подробнее об этом написано тут).

Когда вы регистрируете Site Gateways на стороне Network Hub и добавляете XML-конфигурацию сетевого хаба на стороне площадки, то вы даете им возможность узнать, за какие сетевые зоны отвечают Site Gateways, и где находится Network Hub. Однако виртуальные машины на площадках также должны иметь возможность достучаться до виртуальных машин в других зонах через шлюзы по умолчанию, для того и нужно добавлять статические маршруты. Ведь после того, как трафик через Site Gateway одной площадки доходит до Network Hub, он уже корректно перенаправляется к соответствующей площадке через ее Site Gateway.

Например, у вас есть такая инфраструктура (пример взят отсюда):

Тогда таблица статических маршрутов на сайте MEL будет выглядеть так:

В качестве Next hope тут указан Site Gateway данной площадки, который далее отправит трафик к Veeam PN Server, дальше он будет направлен к машине на другой площадке. Аналогично маршруты будут выглядеть и на других площадках.

Если вы используете Veeam PN Server на стороне Azure добавлять новые маршруты не потребуется - Veeam PN сам добавит все необходимые маршруты в таблицы маршрутизации. Кстати, в качестве компонентов сетевой инфраструктуры Veeam PN можно использовать инфраструктуры на стороне публичных IaaS-сервисов AWS, IBM или Google, а также любого другого публичного облака.

Загрузить бесплатное решение Veeam PN можно по этой ссылке. Там же можно скачать и пробную версию продукта Veeam Recovery to Microsoft Azure.

На прошедшей конференции VMworld 2017 в рамках сессии "VMware Virtual Volumes Technical Deep Dive" компания VMware рассказала о технических аспектах технологии VVols, а также возможностях, которые появятся в следующей версии платформы виртуализации VMware vSphere:

Самый интересный слайд показывают в конце презентации:

Во-первых, надо отметить, что следующая версия vSphere будет иметь номер 6.7, а, во-вторых, давайте посмотрим на три фичи, которые появятся в VVols, подетальнее:

• Support for Microsoft Cluster Server (MSCS) – это была одна из причин, по которой администраторы до сих пор используют RDM, а этот вариант использования не поддерживается со стороны VVols. Данная поддержка позволит расширить сферу использования технологии.
• Performance parity with VMFS – в данном случае цель VMware - обеспечить высокую производительность VVols, поскольку сейчас есть промежуточный компонент Protocol Endpoint, который замедляет работу подсистемы ввода-вывода. Также будут оптимизированы такие операции как bind, соединения VASA, а также обработка метаданных томов VVols. Кстати, в целом-то VVols должна работать даже побыстрее, чем VMFS.
• IPv6 support – платформа vSphere уже давно поддерживает IPv6, а сами VVols будут поддерживать IPv6 на уровне службы VASA Provider.

Поддержка NFS 4.1 и операций BIND/UNBIND/REBIND. Сейчас они делаются через VASA provider, которые идут через control path, поэтому медленные, а будут работать через Protocol Endpoint (то есть data path, что быстрее).

Будем следить за новостями о новых возможностях VMware vSphere 6.7.